Transactional security over a network

ABSTRACT

A system and method facilitates purchase transactions over a computer network, including the purchase of electronically storable items. The embodiments herein encrypt “customer information” in an encryption stream and cause the encryption stream to be transferred from the customer to a merchant in the purchase transaction. A verification entity receives the encryption stream which is sent by the merchant for identity verification and payment authorization. Then, the verification entity verifies the identifiers contained in the encryption stream and transfers an identity verification and payment authorization from the verification entity to the merchant. The encryption stream or unique transaction identifier can be added, by the merchant, to a purchased electronic item to create a personalized electronic item.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of presently pending U.S.application Ser. No. 10/970,051, entitled “METHOD AND APPARATUS TOPROVIDE SECURE PURCHASE TRANSACTION OVER A COMPUTER NETWORK, filed onOct. 21, 2004, which is a continuation of U.S. patent application Ser.No. 09/726,304 filed on Dec. 1, 2000, which has issued as U.S. Pat. No.6,839,692, which are both fully incorporated herein.

This application also claims the priority of presently pendingprovisional application 60/890,230 entitled “ENCRYPTED INDIVIDUALAGREEMENT IDENTIFIERS TO ACQUIRED MEDIA OR MEDIA CONTENT, filed on Feb.16, 2007, which is fully incorporated herein by reference.

BACKGROUND AND SUMMARY Field of the Invention

The embodiments of the invention generally relate to securing eCommerceand similar transactional relationships, including the sales of goodsand services, between parties over computer networks such as theInternet and to tracking of distributed electronic items, such aselectronic documents, electronic presentations, electronic works and tomethods and systems for storing encrypted individual agreementidentifiers within the distributed electronic items.

I. Background and Summary of Original Disclosure

application Ser. No. 10/970,051 and U.S. Pat. No. 6,839,692

Priority Date: Dec. 1, 2000

The present invention generally relates to a system for providingsecurity for purchase transactions made over a network and moreparticularly to an improved security system that only stores andprovides encrypted information. Additionally, the invention relates to asystem for providing customer controlled rules, including time and valuelimits, for purchase transactions made over a network.

The increase in popularity of personal computers and of networksconnecting personal computers has caused a dramatic increase inelectronic commerce (e-Commerce) in recent decades. One example of avery popular network is the World Wide Web (WWW) or Internet. However,one aspect that has been hampering e-commerce is the inability toprovide a convenient and secure payment system.

Many conventional e-commerce payment systems require elaboratepasswords/encoding algorithms that are cumbersome and not user-friendly.Other conventional e-commerce payment systems require all partiesinvolved to agree on a security format. Such systems suffer from thedisadvantage that only those parties that have joined the “club” andhave agreed to the specific encoding format can participate. Consideringthe rate at which merchant sites are being added and withdrawn fromcurrent networks (e.g., Internet), requiring merchants to agree on aspecific format is unrealistic.

Other e-commerce payment systems require prepayments to a third-partyvendor that, in turn, issues a coded credit against that deposit.Besides creating yet another layer to online transactions, these“wallet” and “Internet cash” programs also create another layer ofexposure for the customer's information. Additionally, these systemsrequire that both the customer and merchant register to participate inthe various versions of these systems.

Still other e-commerce payment systems require the user to purchasespecific hardware (e.g., a credit card reader) that is proprietary innature and awkward to install and use. In addition, the user is requiredto transport the hardware device if purchases are to be made at othercomputers, which hampers this type of payment system.

No matter the payment system, the common thread shared by conventionalsystems is that the customer must provide private information in orderto complete a transaction—to the merchant, to a potential third-party,and to the merchant's financial institution. This requirement is thebiggest impediment to conventional systems because of the exposure tothe customer, perceived or otherwise. Whether the customer obtainsadditional hardware or merely entrusts private information tothird-party vendors, the customer's information ends up stored insomeone else's database. The vulnerability of these stored records is amatter of deep concern to potential customers and to policy makers.

The problem is a matter of how many times a customer must exposeprivate, sensitive, and/or confidential information in order to transactbusiness over a network environment such as the Internet.

It is, therefore, an object of the present invention to provide astructure and method of securing purchase transactions over a computernetwork. The invention encrypts customer information as a customer codeon a storage device on a customer computer (the customer computer isconnected to the computer network). Then the invention supplies thecustomer code to a merchant in a purchase transaction over the computernetwork and forwards, or allows the merchant to forward, the customercode to a financial institution over the computer network. The financialinstitution decrypts the customer code, verifies the information, andreturns a purchase authorization decision to the merchant over thecomputer network.

An important feature of the invention is that encoded customerinformation, such as credit card numbers (“customer code”), is notavailable to merchants and, therefore, is not vulnerable to themerchant's security or privacy entrustments. The customer code is storedon the customer's storage device only, and it is in encrypted form. Thisallows the customer to complete merchant transactions without revealingcertain of the encrypted information to the merchant, such as creditcard numbers. The financial institution compares, inter alia, thecustomer address with historic address information of the customermaintained by the financial institution. Customers may maintain morethan one authorized shipping address. The purchase authorizationdecision is approved only if the customer address and the historicaddress are consistent. If authorization is not approved, on the basisof incorrect address information, the options to the financialinstitution include: 1) approving the transaction with the correctedaddress; 2) approving the transaction subject to the customer updatinghis/her address information prior to the issuance of the authorizationcode; and, 3) declining authorization.

Securing the customer's information before it is exposed to a networkenvironment allows the customer to retain control and expand the use ofhis/her credit facility online. This is a paramount difference betweenthe present invention and conventional e-commerce payment systems.

The present invention allows the customer to access his/her informationby means of a personal key, or access code, however only the financialinstitution and its agents possess the decryption key, or code. Thus,the invention provides secure use of the customer's information withoutadding layers or third-parties and without exposing that information toa myriad of databases. In the preferred embodiment, the customer codeincludes encrypted credit card information.

In an additional embodiment, the invention can encrypt many customercodes on the storage device. Each of the customer codes can include aunique payment method. Alternatively, one group of the customer codescan identify a single credit organization for payment, wherein eachcustomer code in the group includes a different user name. This allowseach customer code in the group to include unique credit limits andallows the customer to authorize additional users for a single creditorganization or facility. The invention also uses a password on thecustomer computer to unlock the customer code.

In another embodiment, the invention comprises a system that operates ona customer computer. The inventive system includes an encrypter adaptedto encrypt customer information as a customer code on a storage deviceon the customer computer and a populator adapted to supply the customercode to a merchant in a purchase transaction over the computer network.The customer computer includes a network connection adapted to forwardthe customer code to a financial institution over the computer network.The financial institution decrypts the customer code and returns apurchase authorization decision to the merchant over the computernetwork.

The customer code preferably includes encrypted customer addressinformation, and the system further comprises a comparator located atthe financial institution. The comparator compares the customer addresswith a historic address of the customer maintained by the financialinstitution. The purchase authorization decision is approved only if thecustomer address and the historic address are consistent.

The system can optionally include an intermediate code confirmationsite, external to the customer computer, and connected to the computernetwork. The intermediate code confirmation site receives the customercode prior to forwarding the customer code to the financial institutionover the computer network. The intermediate confirmation site confirmswhether the customer code has a proper encryption format.

The encrypter can also encrypt a plurality of customer codes on thestorage device. As mentioned above, each of the customer codes caninclude a unique payment system or a group of the customer codes canidentify a single credit organization for payment. Each customer code inthe group can have a different user name and unique credit limits. Theinventive system also includes a graphic user interface that can receivea password on the customer computer to unlock the customer code.

II. Background and Summary of Continuation-In-Part Disclosure

Claiming Priority to U.S. Provisional Application 60/890,230

Priority Date: Feb. 16, 2007

The Internet has changed the way people communicate and the way they dobusiness. With that change, the way of doing things on the Internet hasalso evolved. As computers and technology opened a new era, software waspackaged on disks and sold. Downloadable or otherwise transferablemedia, such as digital music and movies, soon followed. This activityled certain individuals and groups to seek ways to profit from theunauthorized copying and sale of these products, which became two basicbusinesses—one that sought to profit by pirating the works of others andanother that tried to prevent the pirates' activity. As the Internetcontinues to evolve, more and more of this media content is beingdownloaded and shared, creating another layer of complexity and anotherarea of concern.

Similarly, content sensitive websites, such as those related to theadult industry and, until recently, the gaming industry, both gained inpopularity and have become a bane to regulation because of the nature ofthe Internet and its lack of a single jurisdiction and enforceablestandards. Efforts have been launched—expensive and complex efforts—toimpose self-regulation and prosecution; however, protecting minors andregulating commerce over what is arguably an international jurisdictionhas proven difficult at best. The compound problem is how to regulate astructure that does not have a conventional “place of business” withoutviolating the rights of the individuals and of the groups who, dependingupon the jurisdictions in which they reside, may have varying degrees ofprivacy rights and legal protections that must be balanced against anyeffort to regulate virtual-jurisdiction and commerce over the Internet.Virtual commerce over a virtual environment creates a need to establishagreements as to rights and jurisdiction for the protection andprosecution of those rights. However, the nature of eCommerce creates anadditional need to identify the consumer, while protecting thatconsumer's identity from “identity theft” and “identity fraud,” andwhile protecting the transaction for both the consumer and the merchant.

Currently, the vendor bares much of the risk in an Internet transaction.If a minor has “borrowed” a parent's credit card, debit card, or prepaidcard, if someone has stolen another person's identity, if someone hasmisrepresented their age as a ploy to enter a restricted site; then, thevendor's claim for payment may be denied. All of these things representa real problem for the eCommerce merchant who seeks compensation forwhat they offer because that merchant assumes the risk for atransaction, not the issuing bank, where there is no signed receipt—“nosignature present.” The result from this is millions of dollars offraud, repudiation, and chargebacks of transactions, which raise thecosts and risks for all.

In view of the foregoing, this disclosure presents a method, system, andstructure that creates, records, verifies, and makes a storable versionof a consumer's encrypted individual agreement identifiers that can be,among other things, embedded with media purchased or otherwise acquiredover a computer network and onto the transactional authorization,receipt and/or record of sale, creating a “person present”/“signaturepresent” verifier.

The method includes the use of any or all user encrypted agreementidentifiers, which are created before or during storage to the user'shard drive or otherwise similar purpose computer storage system. Themethod and system includes allowing encrypted agreement identifiers tobe used without revealing certain of the encrypted information, such asname, address, or credit/debit/prepaid card numbers, to the vendor withwhom a transaction, for instance the purchase of media, is beingconducted. In other words, the need to consistently register and exposea consumer's identity and information with vendors and their databasesis eliminated with embodiments herein.

The method and system allows the encrypted agreement identifiers to beused as a means of verifying user acceptance of qualified terms of useand purchase, in a way that can also be embedded in downloadable media.The method and system creates and controls sub-accounts with unique userreporting and corresponding password identifiers. The method and systemplaces the control responsibility for an account and any sub-accountswith the primary authorized/registered user. The encrypted identifiersenable a method and system for securing and limiting the access and useof the media acquired to the use, terms, and privilege for which it wasacquired, thus allowing for the agreed enforcement of copyrights andother protections.

More specifically, this disclosure presents a system and method offacilitating computerized purchase transactions of electronicallystorable items (which are sometimes referred to herein as electronicitems) such as literary works, musical works (recordings), and videoworks (movies, shows, videos, etc.) wherein the consumer agrees toenforcement of adhering rights, such as copyrights.

The embodiments herein encrypt “customer information” in an encryptionstream (which is sometimes referred to as a customer identifier (CID)code). Such customer identifier information may comprise a nameidentifier (which may or may not be the customer's formal name), apossible customer age identifier (which can be a birthdate, a specificage, an age range, an age classification), a possible address identifier(which can be a customer's address or a different address), and acustomer agreement identifier that contains or identifies thecontractual agreement between the customer and a verification entity orfinancial institution (credit issuer) that will facilitate the purchasetransaction.

It is possible that once the elements of an encryption stream areidentified and agreed upon, a single, unique identifier may be employedby the verification entity to locate and identify that specific streamof customer information (including a computer identifier). The customerinformation is stored only in the verification database and only theidentifier and the at-point-of-sale computer identifier can betransmitted as the encryption stream (together with non-encrypted BIN orcredit issuer routing number) to the vendor.

One intent of the program and the participants is to create a “signaturepresent verified transaction” that may be relied upon by all parties tothe transaction while allowing identity protection for the customer.

The embodiments herein cause the encryption stream to be transferredfrom the customer to a merchant in the purchase transaction for thepurchased electronic item. The verification entity, which may be thecredit issuer or the credit issuer's processor or agent (e.g., theverification entity), receives the encryption stream which (incombination with the purchase price) is sent by the merchant foridentity verification and payment authorization prior to paymentprocessing. Then, the verification entity cross-references theencryption stream against a separate database containing the customerinformation to produce the identity verification and paymentauthorization. Then, the verification entity transfers the identityverification and payment authorization to the merchant, who completesthe transaction with the customer and processes the transaction forpayment as a “signature present” verified transaction by pre-agreementof all parties.

The identity verification and payment authorization confirms to themerchant the actual presence of the customer in the purchasetransaction, such that the merchant is provided assurance that themerchant is not transacting with any entity other than the customer andthat the customer has agreed to be bound by the terms of a transactionverified under the customer-credit issuer agreement. The customer-creditissuer agreement anticipates the use of and reliance upon that agreementin third party transactions, in part, in exchange for identityprotection and the convenience of the embodiments herein.

With embodiments herein, the encryption stream contains identifiers—notnecessarily the personal customer information—that have been agreed uponby and between the customer and the credit issuer (e.g., bank), and theidentity verification and payment authorization contains informationlimited to a unique transaction, as anticipated and agreed upon by andbetween the customer and the credit issuer. Such identifiers would be oflittle use even if the encryption stream is decrypted.

Another feature of embodiments herein is that the encryption stream, ortransaction verification, may be added, by the merchant, to a purchasedelectronic item, such as downloadable digital media, to create apersonalized electronic item. The encryption steam or unique transactionverification (collectively or separately sometimes referred to herein asthe “transaction identifier”) can be hidden, so that the customer isunable to remove the transaction identifier from the personalizedelectronic item. Further, the personalized electronic item could be madenon-functional (so that the personalized electronic item cannot beopened, or cannot be played, etc.) if the encryption stream ortransaction identifier, in part or in whole, is ever removed. Thus, thepersonalized electronic item always maintains the transaction identifierand allows the customer who purchased the electronic item to beidentified (through the verification entity). Additionally, thetransaction identifier is added in such a way that all copies of thepurchased electronic item will have the transaction identifier. Thus,because all copies of the personalized electronic item will have thetransaction identifier, the customer who originally purchased theelectronic item from the merchant (the source of the copies) can alwaysbe identified through reference to the verification entities securedatabase. The “transaction identifier” is what is returned by theverifying entity and, because it is a unique identifier, may also beusable as a media embedded identifier.

After the transaction identifier is added to the purchased electronicitem to create the personalized electronic item, the personalizedelectronic item is supplied from the merchant to the customer. Eachpersonalized electronic item distributed to different customers isdifferent because of the uniqueness of each different transactionidentifier, which allows the customer who originally purchased theelectronic item to be identified in copies of the item. Further, theuniqueness of each transaction identifier permits the source ofunauthorized copies of the purchased electronic item to be identifiedthrough the secure database maintained by the verification entity.

During customer registration (when the customer is setting-up ormodifying their account with the credit issuer) and during the purchaseof electronic items, the customer can be provided with a notice orwarning that their information will always remain with copies of anypersonalized electronic items. In addition, during the purchase of anelectronic item, a similar notice or warning can be displayed informingthe customer that he/she is agreeing to be bound by the terms andpenalties provided for unauthorized use or copying of the electronicitem; and, each time (or the first few times) the personalizedelectronic item is opened, played, etc. the same warning may bedisplayed. Such continuous warnings may or may not be applicable tocertain downloadable media such as music. Such warnings are intended todiscourage the customer from supplying copies of the personalizedelectronic item to others in violation of the rights of the merchant(e.g., illegally uploading or copying) because the customer is madeaware, through the warnings, that the illegal uploading or copying canbe traced back to them through the verification entity using thetransaction identifier and/or encryption stream and is agreeing to bebound by the conditions and terms set forth in those warnings. Similarauthorized use and acceptance warnings may also be employed for accessbased upon age, sale pricing based upon age or residence, etc. Theembodiments herein allow for a wide range of customer identifiers thatencourage, promote, and protect eCommerce and the parties engaging init.

The copyright warnings, etc., may not be applicable to audio media afterit is downloaded. These warnings are important prior to any downloading,however, to the extent that the customer is agreeing to be bound by theterms and conditions contained in such warnings as a condition of thetransaction, he/she is agreeing to be bound under the adhesionprovisions of his/her agreement with the credit issuer and is agreeingto be liable for breach of terms and conditions. The parties areagreeing to be responsible for their actions and intensions.

The encrypting of the customer information can be, for example,performed as follows. First, the customer connects with the creditissuer using a first computerized device and the credit issuer downloadssoftware to the first computerized device. Vendors (which areinterchangeably sometimes referred to herein as “merchants”) may alsoact as a registering agent for a credit issuer by redirecting a customerto the credit issuer's site for registration with the verificationentity. The advantage to this, for example, is that once an existingcredit card user registers his/her card under the program, thatuser/customer may elect to restrict the use of the “card” on a computernetwork such as the Internet to embodiments herein, protecting the“card” from unauthorized use by others. The customer supplies or agreesto allow storage of existing sensitive information, such as validshipping addresses, their date of birth (for age group classification),their bank account numbers, credit card numbers, etc. Certain items ofthe customer information (such as bank account numbers and credit cardnumbers) are not stored on the customer's computerized device, butinstead are only maintained in the databases of the credit issuer or theverification entity, though coded or un-coded identifiers may be used tospecifically reference such information. Other items or identifiers(name, address, age reference, etc.) of the customer information may beencrypted to create the encryption stream, which is stored on thecustomer's computerized device and which may be coded or un-coded priorto encryption, in part or in whole.

The term “credit issuer” herein is a shorthand term for the entity thatextends credit to the customer. This can be a merchant, vendor, bank,financial institution, etc. Further, any such credit issuers can includea verification entity and can act through an agent. Therefore, the term“credit issuer” is used to represent any and all of the foregoing. Thecredit issuer, as discussed in this document, may be one of severaltypes. One type is a credit card, debit card, or similar type of issuer.Another type of issuer could be an entity that allows existing creditvehicle holders, such as existing credit card holders, to register allof the “cards” they wish to use with a single entity which would thenact as the processor. Another type could be a non-card/non-bank type ofcredit issuer, such as a Microsoft® or a Yahoo!® or a Google®, thatdetermines a line-of-credit for an individual, on a case by case basis,and extends to them an identifiable credit amount that may be used bythe individual over a network such as the Internet. One ordinarilyskilled in the art would understand that there are many other types ofcredit issuers that are not listed here, but that could be components ofembodiments herein.

Credits are processed by the credit issuer or its processor, sometimesacting as the verifier, with participating vendors that do business overthe network (this alternative recognizes that conventional credit cardsmay not be necessary on a computer type of network and that what isnecessary is the need to protect the parties to the transaction whiletracking the flow of legitimate commerce). The vendors may choose topromote this program by referring customers to their credit issuer forenrollment. This protects the customer and his/her identity, improvesthe marketability of the vendor, assures the vendor of payment, andreduces chargebacks and fraud; all serving to improve the vendor'sbottom-line.

Banks and software companies are capable of reading and verifying acomputer's identity without downloading software onto a “visitor's”computer; however, software can be downloaded or otherwise installed inorder to perform the other tasks. With the customer's authorization, thecredit issuer reads and registers the unique hardware identifiers (suchas serial numbers from the motherboard, the hard drives, the processor,etc.) from the first computerized device. These unique hardwareidentifiers are also incorporated into the encryption stream. Then, thesame steps are repeated for any additional computerized devices thecustomer desires to authorize and register for use in future purchasetransactions, if, for example, the customer owns or has access tomultiple computers and computerized devices. Such processes can be donewhen the customer is setting up or modifying their account with thecredit issuer.

The verification entity, financial institution, and/or credit issuer,(e.g., a bank), sets up the elements of the encryption stream with thecustomer, including the initial contract/agreement that will be reliedupon by any vendor supporting this program. It is the agreement betweenthe credit issuer and the customer that is relied upon by the vendorunder the terms of its merchant bank/acquirer agreement. Also, theverifying entity may be the credit issuer, or it may be a processor oragent used by the credit issuer, which processor or agent has access tothe database containing the customer's information.

Some examples of customer types include: 1) new customer (applying forcomputer network credit; a new credit card; a new debit card or otherform of “loaded” card such as a payroll debit card); 2) existingrelationship (holder of an existing credit vehicle, such as the types innumber 1, above, that may be used for purchases over a computer networksuch as the internet); or 3) new customer with existing credit vehicle(a person with existing credit vehicles/cards, such as the typedescribed in number 1, above, may chose to register some or all of those“cards” with a single entity that would allow the “program” to beattached to all of the registered “cards”).

The “credit” may be in the form of an existing credit card, debit card,etc., or it may take the form of a newly issued “credit” from some othersource willing to extend such credit to an identifiable individual—asort of electronic-letter-of-credit, or eCredit—subject to various rulesand regulations. It is during the process of registering the customer'sidentifiers and other information with this credit issuer—a bank willpresumably have an existing customer's information in its database—thatthe customer and the credit issuer form the agreement of whatidentifiers are to be present, along with the hardware information ofthe registered device(s), to confirm the customer's presence.

Elements of the customer information such as age identification can beextrapolated from the database, rather than being stored in theencryption stream, although a date-of-birth or a unique word may be partof the encryption stream.

In another embodiment, as one process of further verifying that themerchant is dealing with no one else other than the customer, at theapproximate time of transfer of the encryption stream to the merchant,but before the actual transfer of the encryption stream to the merchant(as part of the process of transferring the encryption stream) themethod can incorporate, into the encryption stream, a second set ofcomputer hardware identifiers and a time and date stamp from thecomputerized device making the actual transfer of the encryption stream.Thus, if an unscrupulous person were able to obtain an improper copy ofthe encryption stream, and was using the improper copy of the encryptionstream on a computer (other than one of the customer's computers thatare registered with the verification entity) possibly together with thenecessary credit issuer supplied encryption stream creation and transfersoftware, the second hardware identifiers that are readjust prior to thetransfer of the encryption stream would not match the hardwareidentifiers in the encryption stream and the transaction would not beapproved by the verification entity. Similarly, the time and date stampcould be used to make the encryption stream that is supplied to themerchant only valid for a limited time period (e.g., minutes, hours,days, etc.). Such processes further enhance the “customer presence”verification process performed by the verification entity to provideadditional assurances to the vendor that they are actually dealing withthe customer and not someone other than the actual customer. In additionto verifying the customer's presence and agreement to terms whenever thecustomer uses the encryption steam/signature, the embodiments hereinpermit the credit issuer to disallow a specific vendor into the program,where vendor fraud is, or has been, an issue. This further serves toprotect the customer, as well as reputable vendors.

The use of a standard credit issuer software program for creation of theencryption stream on the customer's computerized device and the transferthe encryption stream to the merchant for the verification step ensuresthat the device upon which the software resides will be identified.Thus, if that identifier does not match the identifier in a hypothecatedencryption stream, the transaction will not be approved.

Embodiments herein also comprise one or more systems that use an encoderthat is positioned within the customer's computer by the credit issuer.The encoder encrypts the customer identifier information in theencryption stream. In addition, the credit issuer positions a transferagent within the customer's computer and with the merchant. The transferagent causes the encryption stream to be transferred from the customer'scomputer to the merchant's computer in the purchase transaction for thepurchased electronic item.

The verification entity has a verifier that is operatively connected toboth the customer's computer and/or the merchant's computer during theverification stage of a transaction. In embodiments herein, in order toenhance the security of the customer information, the verifier ismaintained separate from the customer's computer and from the merchantby being maintained in the verification entity. A database of thecustomer payment information can be maintained within the verificationentity or separate from the verification entity. In either situation,the database is operatively connected only to the verifier, and neitherthe customer nor the merchant have access to the database.

To perform the method steps herein, the transfer agent is adapted tocause the encryption stream to be transferred from the merchant'scomputer to the verifier for payment verification. The verifier isfurther adapted to generate the identity verification and paymentauthorization, based on the database information, and to transfer theidentity verification and payment authorization to the merchant. Again,the encryption stream or the unique identity verification and paymentauthorization is adapted to be added, by the merchant, to the purchasedelectronic item to create the personalized electronic item that issupplied from the merchant to the customer.

These and other aspects of the embodiments of the invention will bebetter appreciated and understood when considered in conjunction withthe following description and the accompanying drawings. It should beunderstood, however, that the following descriptions, while indicatingpreferred embodiments of the invention and numerous specific detailsthereof, are given by way of illustration and not of limitation. Manychanges and modifications may be made within the scope of theembodiments of the invention without departing from the spirit thereof,and the embodiments of the invention include all such modifications.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments of the invention will be better understood from thefollowing detailed description with reference to the drawings, in which:

FIG. 1 is a schematic architectural diagram of one embodiment of theinvention;

FIG. 2 is a flow diagram illustrating an embodiment of the invention;

FIG. 3 is a flow diagram illustrating an embodiment of the invention;

FIG. 4 is a schematic diagram of a system embodiment herein;

FIG. 5 is a schematic diagram of a system embodiment herein;

FIG. 6 is a schematic diagram of an encryption stream according toembodiments herein;

FIG. 7 is a flow diagram illustrating a method embodiment herein;

FIG. 8 is a flow diagram illustrating a method embodiment herein;

FIG. 9 is a flow diagram illustrating a method embodiment herein; and

FIG. 10 is a schematic diagram of a system embodiment herein.

DETAILED DESCRIPTION OF EMBODIMENTS

The embodiments of the invention and the various features andadvantageous details thereof are explained more fully with reference tothe non-limiting embodiments that are illustrated in the accompanyingdrawings and detailed in the following description. It should be notedthat the features illustrated in the drawings are not necessarily drawnto scale. Descriptions of well-known components and processingtechniques are omitted so as to not unnecessarily obscure theembodiments of the invention. The examples used herein are intendedmerely to facilitate an understanding of ways in which the embodimentsof the invention may be practiced and to further enable those of skillin the art to practice the embodiments of the invention. Accordingly,the examples should not be construed as limiting the scope of theembodiments of the invention.

I. Detailed Description of Original Disclosure

application Ser. No. 10/970,051 and U.S. Pat. No. 6,839,692

Priority Date: Dec. 1, 2000

Referring now to the drawings, and more particularly to FIG. 1, aschematic diagram of a preferred embodiment of the invention isillustrated. More specifically, FIG. 1 illustrates a personal computer100 connected to a network 170. In addition, a code confirmation site130, merchant site 140, financial institution 150, and credit agency 160are also connected to the network 170. The arrangement of features shownin FIG. 1 is arbitrarily selected in order to illustrate the invention.One ordinarily skilled in the art would understand that many otherarrangements of items could be utilized with the invention.

The personal computer 100 (which is sometimes referred to herein has the“customer's computer”) comprises any form of computing device that iscapable of connecting with the network 170. Therefore, the customer'scomputer 100 can comprise a standard desktop personal computer, a mobilecomputer, a personal digital assistant, a cell phone, etc. In apreferred embodiment, the customer's computer 100 includes a graphicuser interface (GUI) 110, and a storage device 112, such as a magnetichard drive or other read/write storage device. In addition, thecustomer's computer 100 includes an encrypter 114, a network connection116, a populator 118 and central processing unit (CPU) 120.

The financial institution 150 includes a database of historical address154 obtained from the credit agency 160 and a comparator 152 that isutilized to check customer addresses, as discussed below.

The operation of the system shown in FIG. 1 is illustrated in flowchartform in FIG. 2. More specifically, the inventive system is added to thecustomer's computer 100. Using the graphic user interface 110, thecustomer preferably creates a password as shown in item 200 that willallow future access to the inventive system. The customer then suppliespersonal information such as Social Security number, address, date ofbirth, relatives' names, credit card information, banking information,employment information, etc. to the inventive system through the graphicuser interface 110. The encrypter 114 immediately encrypts thisinformation and stores the encrypted information as a customer code onthe storage device 112, as shown in item 202.

An important feature of the invention is that the customers' personalinformation is only stored in encrypted form. Therefore, if anunauthorized user were able to access the user's storage device 112, thecustomers' personal information would be secure because of its encryptednature.

The encryption process has three elements: 1) the encryption codeitself, which is pared to the decryption code maintained by thefinancial institution; 2) the customer's private key, password and/orpersonal access code, which is created and controlled by the customerfor accessing the encrypted information; and, 3) the customer'scomputer's system identifier that requires that the encryptedinformation may only be accessed on the customer's computer. Once thecustomer's information is entered, these three elements and the need tore-enter any of the information become transparent to all parties duringany e-commerce transaction (e.g., dual key or public key).

If the encryption code were to fall into the hands of an unauthorizedparty, access to the information would still require the customer'sprivate key plus access to the information from customer's specificstorage system (e.g., customer's computer's system identifier). Anunauthorized user would need the decryption code to access theinformation, which code is maintained only by the financial institutions(credit issuers) and their authorized agents. This element of the“public key” or “dual key” format of the preferred embodiment of thepresent invention enhances the security of the customer's information.

Even if an unauthorized user overcomes the foregoing safeguards, thepresent invention requires the user to supply an authorized shippingaddress; a procedure that requires a separate secured transaction withthe financial institution, confirmed by e-mail to the customer. Suchsteps make impractical the unauthorized access.

In another embodiment of the invention, the user can create multiplecustomer codes, each of which could include a different credit agency(e.g., a different credit card). Therefore, the invention allows theuser to create a customer code for each of the credit cards the userowns.

In addition, many customer codes can be created for the same creditcard. These additional customer codes can include different spendinglimits. This allows the user to establish different customer codes forbudgetary or other similar reasons. For example, with the invention, auser could create customer codes for different items of a personal orbusiness budget. Upon reaching a spending limit, no additionaltransactions (purchases) could be performed until the budget informationis changed or updated. The budget plan could be updated automatically toallow periodic budgets to be automatically implemented. An example ofthis could include one customer code that uses a credit card to paymonthly charges to an internet service provider (ISP) for a specificperiod, e.g., one year. The customer code would include a monthly limitof the monthly ISP fee and a twelve-month limit on the transaction. Theadditional advantage to the customer of this embodiment is the abilityto amend or cancel the transaction at any time by changing the statedlimits.

Similarly, parents could create customer codes for each of theirchildren, where each customer code potentially includes a differentspending limit. In one embodiment, the spending limits can be updatedperiodically to provide a periodic allowance. This aspect of theinvention allows parents to establish a monthly Internet-allowance for achild. The parents establish a separately authorized customer codetogether with periodic limits (e.g., monthly or weekly). The effect ofthis is that the parent would control the establishment and use ofauthorized sub-accounts.

The effect of these aspects of the invention is that the financialinstitution would continue to control qualifying a customer for credit.However, the customer would enjoy an increased control and use of thatcredit.

The customer codes preferably include the name, address and credit cardnumber of the user in encrypted form. Once the customer codes have beenestablished and stored in encrypted form on the storage 112, theinvention operates in the background on the customer's computer 100until the customer desires to make a purchase over the network 170. Atthe time of a purchase, the graphic user interface 110 provides the userwith different payment options (customer codes). After the user selectsthe appropriate customer code, the populator 118 prepares to send thecustomer code to the merchant's site 140 by issuing an instruction tosend the customer code out on the network 170 directed to the merchantsite 140, as shown in item 204.

The operation of the functions in item 204 is shown in greater detail inFIG. 3. More specifically, the invention provides for the customer codeto automatically populate the appropriate “checkout” box of the merchantsite 140 using the populator 118. As shown in FIG. 3, when the customergets to a checkout (purchase) window of a merchant site, (300) thecustomer places the cursor into the appropriate box (e.g., the creditcard number field, customer code data fields, etc.) 302. Many merchantsites 140 may not have space for the customer code date field.Therefore, the invention allows the credit card number (or other similarpayment filed) to be used by the merchant site. The encrypted customercode data field is longer than credit card numbers. Therefore, the onlymodification needed by the merchant site 140 to accommodate theinvention is to allow longer encrypted data strings to be accepted bythe credit card number field.

Once the user places the cursor in the appropriate box, they press apre-established function key on the keyboard (or selects a button on thegraphic user interface) (304) which brings up a user ID and passwordentry pop-up window (306). Upon entry of the proper user ID andpassword, the entire customer code is populated (written to) the fieldon the merchant site. The user does not need to enter their name,address, etc. because all that information is contained in the customercode. As discussed below, upon approval of the credit transaction, thefinancial institution 150 will return name, shipping address and creditauthorization number (not credit card number) to the merchant site 140so that the user does not need to input such information.

If multiple customer codes are established for different credit cards,the user can select a customer code, which includes information as to acredit card with a sufficient credit limit, desirable interest rate,etc. to make the purchase. The customer code itself is the encryptedpersonal information data stream and can be somewhat lengthy. Therefore,the graphic user interface provides a user-friendly selection menu withabbreviated names. For example, in one embodiment, a pull-down menu withcredit card abbreviations is provided to allow the user to select thecustomer code to be used. If the user has established only one customercode, the pull down menu will include only that single customer codeabbreviation. In a similar manner, different budget categories orchildren's names could also be utilized as the abbreviated names in thepull-down menu to select the appropriate customer code.

The user ID's are the customer codes abbreviations. An error message isgenerated if the user ID/password is incorrect (310) and processingreturns to box 304 to retry the user ID/password. As is well-known alimited number of retries of the user ID/password will be allowed.

If the password/user ID is correct (308), the customer has the option toset up rules regarding payment (312), such as the automatic monthly ISPpayments discussed above. If no special rules are to be established forpayment, a single direct payment scheme is assumed and processingproceeds to box 316. On the other hand, if payment rules are to beestablished, another window pops-up (314) to lead the customer through awizard to setup payment options such as transaction amounts, totalcredit limits, and/or time frames, etc.

In item 316, the invention then takes the previously encrypted sensitivecustomer data, and adds to it a purchase specific transaction number andrules (if any). The invention also encrypts such additional data(transaction number, rules, etc.) before attaching necessary routinginformation, and automatically populates the complete customer code intothe customer code data field or credit card field 302. As mentionedabove, the customer code is the encrypted data string of a number ofdata pieces including credit card number, rules, transaction number,customer name and address, etc.

Referring again to FIG. 2, in one embodiment the invention sends thecustomer code directly to the merchant site 140, as shown in item 208.In another embodiment, a code confirmation site 130 is utilized (item206). In this embodiment, the customer code is directed to the codeconfirmation site 130 instead of to the merchant site 140 by thepopulator 118. The code confirmation site 130, controlled by the creditagency, determines whether the customer code has the proper format byallowing the credit agency to periodically update or change the publickeys (e.g., the encryption and decryption codes). If the customer codeis determined to be improper by the code confirmation unit 130, an errorreport is issued explaining that the customer code is improper, as shownin item 212. If the customer code is proper, it is sent to the merchantsite 140 by the code confirmation unit 130, as shown in item 214.

Upon receipt of the customer code, the merchant site 140 forwards thecustomer code to the 150. An important feature of the invention is thatconfidential information is not provided to the merchant in unencryptedform at any time. Thus, the merchant is relieved of the responsibilityfor that information.

As shown in item 218, the decrypts the customer code. Next, whilechecking whether the credit transaction is acceptable (e.g., whether thecustomer has sufficient credit available), the also compares, using thecomparator 152, the shipping address to which the goods are to beshipped against a historical database of acceptable shipping addresses154 that is provided to the by the credit agency 160. This aspect of theinvention prevents items from being improperly diverted by criminals toaddresses other than the customer's address.

In one embodiment of the invention, the customer is able to establishmultiple authorized shipping addresses directly with the credit agency.These addresses may include such alternatives as office or home. Eachaddress is entered and stored on the customer's storage device with aseparate encryption sequence as a separate customer code. At the timethe customer is setting up new customer codes, new authorized addressesfor the customer are sent (via e-mail or similar electronic transfer)directly from the customer's computer 100 to the credit agency 160 overthe network 170 and are augmented to the list of authorized addressesassociated with the customer in the credit agency's 160 databases.

As shown in item 220, if the shipping address is consistent with anaddress in the database 154 and the customer has sufficient credit, aconfirmation code, name, address, and other required information is sentto the merchant 140, as shown in item 224. In this instance, the term“consistent” means that the two addresses must be substantiallymatching. Thus, if a small portion of the street number or zip code isincorrect or if the spelling of the street name is slightly off, thetransaction is approved and a corrected address is provided to themerchant. However, if the shipping address is directed to an addressthat is not consistent with an authorized address for that customer(e.g. different state, different city, different street, etc.), an errorreport is issued to the merchant site 140 and an e-mail is sent to thecustomer explaining the improper transaction.

Credit agencies currently use addresses to help determine authorization;However, their criteria for what constitutes a “consistent” addressvaries. The present invention creates a system for eliminating error andfraud in these authorizations by “correcting” the address. It is thenthe merchant's responsibility to ensure that the product only ships tothe authorized or corrected address. This aspect of the presentinvention adds a layer of security, allowing the customer to “intercept”and return any unauthorized shipments.

In one embodiment of the invention, the customer uses the “rule wizard”to temporarily add a “non-permanent” shipping address, allowing thecustomer to send gifts, etc., to others. The customer's computer'ssystem identifier and password are required to access the “wizard” forthis non-recurring change. Additionally, a confirmation of this shipmentto a non-authorized address is e-mailed to the customer so that thecustomer may be alerted if a fraudulent transaction were beingattempted.

As mentioned above, the merchant site 140 preferably includes an inputfield (which may be the current credit card field) properly formatted toreceive the customer code. The format of the input field is establishedby the credit agency 160 and is similarly required by the financialinstitution 150. There are a relatively small number of national creditagencies 160 (Visa®, MasterCard®, American Express®, etc.). The creditagency 160 can generally dictate the format of information that must besupplied by the more numerous financial institutions 150 that deal withthe credit agency 160. In turn, merchant sites 140 that desired to dealwith the financial institutions 150 must comply with the data formatrequirements of the financial institution 150 (and, in turn, the creditagency 160). Therefore, the invention is applicable to a network thatcontinually adds and drops large numbers of merchant sites 140, such asthe Internet. More specifically, as merchant sites 140 are added to thenetwork, each merchant site 140 will comply with the requirements of thefinancial institution 150 and will include the specialized format of thecustomer code data field in their merchant sites 140. Therefore, theuser should find the customer code data field on the vast majority ofWeb sites that allow customer purchases.

In other words, the invention works with the relatively small number ofnational credit agencies 160 to establish a format (that can potentiallyvary from credit card agency to credit card agency) that will be madeavailable by the merchants 140. Because a limited number of creditagencies 160 control the majority of the online credit purchasetransactions, the format of the customer code input field will beprovided upon the vast majority of merchant sites 140. Thus, theinvention provides the user with access to virtually all merchant sites140 that desire to deal with financial institutions (which is virtuallyall merchant sites that desire to complete purchase transactions).

The credit agencies [160] are in the business of getting customers touse credit (e.g., their credit cards). Where the present inventioncreates security for the customer, together with additional control anduse features, the credit agencies derive a promotional benefit for theircredit facilities. Moreover, these beneficial features do not requireextra steps. A benefit of the present invention is that it eliminatessteps that include repeated entry of customer information or the postingof that information on third-party databases.

An important safety feature of the invention is that the merchant site140 never gains access to the customer's confidential information, suchas credit card numbers. To the contrary, the merchant site 140 onlyreceives the encrypted customer code from the customer 100 and thetransaction confirmation code (and possibly a corrected address) fromthe financial institution 150. Therefore, if any of the foregoingtransactions over the network 170 are intercepted or if the merchantsite suffers an unauthorized access of its records, the customer'scredit card information will be secure.

Further, the invention avoids many of the problems associated withconventional secured network transactions. More specifically, allelements of the present invention must be in place for a transaction tobe completed. Conventional systems provide one level of security to alltransactions, so that if a database is breached all of the records onthat “secured” site are accessible. The present invention protectsindividual records creating an additional level of security.

The benefits that flow from the present invention, as detailed above,include security to an individual customer's online credit and thecustomer's control and flexible use of that credit.

II. Detailed Description of Continuation-In-Part Embodiments

Claiming Priority to U.S. Provisional Application 60/890,230

Priority Date: Feb. 16, 2007

The present invention solves the problem of regulation over the manyreal jurisdictions covered by the virtual worldwide nature of theInternet by providing a system and method for creating individualcovenants on individual transactions—covenants that create definedrights and protections for each party engaging in Internet commerce. Bycreating enforceable terms of agreeing between parties, each of whomhave a valid expectation of reliance on each other (e.g., an expectationthat each is “of age” or is otherwise the person authorized to engage inand take responsibility for such a transaction) and by creating a way ofadhering to such agreements, including the agreement to be bound by theterms of all purchases verified under such agreements and to eachtransactional activity between the parties, the invention createsjurisdictional and enforceable rights based upon an asset jurisdictionof each party rather than upon the virtual environment of theircommercial activity.

One embodiment herein is centered around a contract (“customeragreement”) created between a customer and credit issuer. The customeragreement allows the credit issuer, either acting as a verifier oracting through an authorized processor or agent, to authorize and verifytransactions between the customer and various participating vendors.Various to customer-vendor agreements are anticipated and allowed underthe customer-credit issuer agreement and various, direct or indirect,credit issuer-vendor agreements are also anticipated and allowed underthe customer-credit issuer agreement. There are also agreements orcontracts between the verification entity, which can be a stand aloneentity or combined with the financial institution that issues credit,debit and/or prepaid cards, or other capable financial provider and theindividual customer/consumer.

The customer agreement is the center of all activity in embodimentsherein. It sets the rules and terms by which a customer is bound—i.e.,the price for securing an individual's identity over a computer Networkis that individual's agreement to be legally bound by his/hertransactions whenever all agreed elements that establish the individualsonline identity (e.g., his/her registered computer with the otheridentifiers that distinguish this individual from others that may use orhave access to that computer). This agreement covers the purchase (i.e.,agreement to be responsible and pay) and agreement to terms, such ashonoring any copyright or trademarks attached thereto and agreement tobe legally and personally accountable for the criminal and civilpenalties covering those registered rights. Most importantly, thiscredit issuer-customer agreement/contract gives permission to the creditissuer to reference the customer agreement and adhere its terms to anyverified customer-vendor agreement/transaction. The customer agreement,applied to any credit issuer-vendor agreement, direct or indirect,allows the vendor to rely upon the credit issuer-customer agreement inverifying the customer-vendor agreement. In other words, the vendor'spayment is assured for employing this payment device and does notrequire the individual to disclose, register, or otherwise give uphis/her secure identity.

The customer agreement serves as the center for the relatedtransactional activities that may be controlled under the embodimentsherein. These related activities include: any verifiable transactionbetween the customer and the merchant over a computer network, whichtransaction may be for such things as goods or services; and, thetransaction ultimately facilitated by the contract, directly orindirectly, between the vendor and the financial entity (“vendoragreement”), under which the vendor's consideration for thecustomer-vendor transaction may be guaranteed or “bonded.” Under theterms of the customer agreement, the merchant's consideration may takethe form of such things as payment, credit worthiness, agreement toterms of sale or use of the merchant's offering, or any other terms ofsuch agreement between the customer and the merchant that the contractmay cover and that the verification entity confirms during the initialtransaction to the merchant.

The contracts formed under the embodiments herein create, inter alia,terms of use, third party reliance, and legal jurisdiction. Thus, usingembodiments herein, the parties could agree that the proper jurisdictionfor adjudicating disputes is the business location of the merchant, thelocation of a customer dealing with a merchant, or any other location ofchoice. Terms of use include a “person present” guarantee (akin to“signature present”) to ensure that the merchant is only dealing withthe identified customer and to assure that the merchant will be paidwithout suffering from chargebacks. This person present guarantee isaccomplished when all registered customer identification elements arepresent at the time of the transaction, which is confirmed by theverification entity.

The verification entity certifies both sides of the transaction underthe terms of the customer-credit issuer agreement and the vendor-creditissuer agreement, allowing all terms, e.g., confirmation ofpurchase/“signature present”, agreement of copyright protection, orrepresentation age verification to be enforced and relied upon. Inessence, any customer information that the credit issuer holds could berelied upon by a third party, without actually revealing the customer'sinformation or customer's identity. In this respect, the credit issueracts as a holder of trust on behalf of both the customer and themerchant, and the verifying entity certifies this with each individualtransaction. This could be a bonded or escrowed type of element to thetransaction that protects the identity of the customer and the rights ofthe merchant, and an element upon which the vendor may separately rely.

The common terms of purchase over networks, such as the Internet,involve the use of a bank issued credit card or debit card—in essence,whether the transaction is based upon a credit or prepaid type of card,the issuing bank acts to extend credit based upon the card until thepayment is actually received, if at all, by the vendor. In commonpractice, this payment procedure has the bank wearing two hats: that ofan “issuing bank”; and, that of an “acquiring bank.” As an issuing bank,the bank issues credit and a card to a customer for use in purchasinggoods, services, etc. As an acquiring bank, the bank agrees to acquire(and to pay for) the debt created by the use of those credit cards.Under terms of a conventional credit card transaction over the Internet,a bank, acting as an “issuing bank,” uses its agreement for use of thecard according to terms that require payment and interest on any unpaidbalance. Under a separate type of agreement, a bank, acting as an“acquiring bank,” requires merchants, among things, to verify theidentity of the credit card user and to get the cardholder to sign areceipt for whatever is purchased. This over-simplified explanation ofcredit card transactions is sufficient to point out the problem ofunauthorized credit card use and identity verification for transactionsover the Internet, or any similar system of computer connected commerce.

The vendor-credit issuer agreement takes the additional role ofscreening qualified vendors. One component of eCommerce fraud is vendorfraud. Vendors with known or suspected fraudulent histories can havetheir agreements cancelled and otherwise be denied access to thesignature-present payment terms provided herein and other protections,such as copyright. This vendor qualifying step is necessary both toprotect the customer and to limit fraud.

In view of such problems, the system and process embodiments herein usean encrypted code (“encryption stream”) that allows a third partyverification entity to verify the presence of the customer to themerchant, and to verify the customer's agreement with the credit issuer,the terms of which allow the verification entity to confirm thecustomer's identity and agreement to be bound by the terms of thetransaction with the vendor, including “signature present” payment.Alternatively, rather than just referencing an identifier of thecustomer agreement in the encryption stream, the entire receipt andterms of the transaction could be encrypted and included in theencryption stream.

The customer-vendor agreement is verified under terms of the creditissuer-customer agreement and, in reliance upon it, the creditissuer-vendor agreement, which secure the terms of the customer-vendoragreement through agreed adhesion of the first two agreements. Thecustomer-vendor agreement is the anticipated result any purpose of theother two agreements, which anticipate that all parties will be bound bytheir part of the separate agreements once at such point as the creditissuer or its agent, such as a processor, verifies the customer'spresence and agreement to terms of the transaction—according to thecustomer's request, which is triggered by presentation of the verifiableencryption stream.

Thus, in some embodiments herein, the separate customer agreement(between the verification entity or credit issuer and the customer) andthe separate merchant agreement (between the merchant and its merchantbank) require the customer and the merchant to enter into the customeragreement (between the merchant and the customer) that is created at thetime of the purchase transaction between the merchant and the customer.The embodiments herein provide the ability of the credit issuer toscreen vendors as a further protection to customers. With embodimentsherein a new customer agreement can be created for each purchasetransaction between a merchant and a customer, which, inter alia, bindsthe customer, if applicable to a specific transaction, to observe theintellectual property rights of the merchant or media and which makesbinding statements, if applicable to a specific transaction, regardingthe presence, identity, age, etc. of the customer.

The verification entity is bound under the terms of the credit issuer'sagreement with the customer, and through that agreement the otherparties, to protect the identity and transaction of the customer and toverify, authorize, and protect the payment and other terms of thetransaction (such as age, identity, area of residence, agreement tohonor/be bound by copyright terms, etc.) on behalf of the merchant.

Before an encryption stream is created (at the time of the purchasetransaction) certain elements must be present to confirm the individualcustomer's identity and to verify that the customer has agreed to bebound by the terms of the instant customer agreement. This sequence ofelements may include, among other things, a name (not necessarily thecardholder's name), an address for shipping or confirming residentialstatus (not necessarily the cardholder's billing address), thecustomer's unique credit number or ID with the financial entity, and theregistered hardware identity of the computer, or computers, that thecustomer intends to authorize for such transactions. The encryptionstream is created from some of these elements, such as name, address,customer agreement identifier, computer hardware identifier, etc. butdoes not include sensitive information, such as the customer's creditcard number or bank account numbers. In addition, the BIN (BankIdentification Number) or other routing identifier, such as an IPaddress, which is not encrypted, is added to the encryption stream forrouting purposes.

Under the terms of the contract between the credit issuer and thecustomer, which is created during this registration, all requiredelements of the encryption stream must be present in order for theverification entity to confirm a customer's presence during atransaction with a merchant. The merchant may not be aware of thecustomer's identity because such information is encrypted. Once theverification has confirmed the presence of all coded elements, thetransaction is confirmed, the merchant is instructed where to ship, ifthat information is required, and the merchant's requirement forreceiving a signature and verifying the identity of the customer aresatisfied (i.e., the merchant will be paid, and/or will have recoursefor such terms of the transaction as age verification and/or copyright).

The invention uses the terms created by the customer in forming his/heragreement with the credit issuer. This agreement has the customer assumeresponsibility for all transactions where all required elements of anyof the customer's encryption streams are present. The agreement alsoallows the encryption stream to be downloaded along with any digitalmedia being acquired by the customer as a record of the agreement to theterms of use, such as copyright protection.

One aspect of this invention is that it is a system and method forcreating, verifying, and imbedding (when necessary) a contractuallyagreed upon “code” that, when used with all elements present, acts as asignature, unique to the individual customer, confirming the presence ofthe customer in the transaction. The merchant has the right to rely uponthe terms agreed to by the customer (which also confirms identity andjurisdiction) for the transaction in the customer agreement. Thisinvention offers identity protection in exchange for contractuallybinding all parties to the terms of such transactions. Thus, theinvention provides the ability to protect the privacy and identity of acustomer initiating an Internet purchase transaction, while alsoprotecting the rights and commercial benefits of the merchant providingthe product, service, etc. The embodiments herein protect the identityof the customer, which remains encrypted and/or otherwise protectedunless the terms of the agreement are breached or otherwise violated.

Removal of the “code” would render the media unusable, as described inU.S. Patent Publication 2007/0061580 (incorporated herein by reference)where the absence of a watermark or code prevents the purchased productfrom being accessed from electronic storage media. The presence of the“code” in multiple copies of the media, in violation of the terms ofpurchase and the copyright protections, would give the merchant theability to hold the customer responsible for the multiple copies underthe agreement terms and jurisdiction of the credit issuer. Thus, thecustomer agreement is a vehicle for prosecution of the violation of thecopyright protections specifically agreed to during the purchase.

In sum, the invention creates a method, system, structure, and apparatusfor promoting, protecting, and verifying commerce over computernetworks, such as the Internet, by protecting the rights of thecustomer, including the customer's identity and financial information,and the rights of the merchant, including the merchant's payment and themerchant's control and ownership of its product and/or service, in part,by establishing an agreed upon jurisdiction for the protection andprosecution of those various rights. Thus, the embodiments herein createa binding contract between the parties to a transaction by giving thecredit issuer and verification entity the contracted ability, by consentof the customer and merchant. The embodiments herein confirm that theidentity and credit worthy elements of the transaction have been met,while protecting the identity of the customer and guaranteeing themerchant that it will be compensated. Thus, the invention may be used toestablish a “verified presence” element to the transaction, establish a“signature present” element to the transaction, establish the customer'sage (e.g., in terms of “over 18” or “over 21” or “over 65”), establish aresidential or delivery element, establish a customer/seller nexus tothe customer agreement, and establish the customer's identity (withoutnecessarily revealing it or storing it online) all, in part, byrequiring that all components of the encryption stream be present and beverified in order for a transaction to be completed.

Referring now to the drawings, the present embodiments provide a methodand system of securing transactional rights over a computer network 404.As shown in FIG. 4, the terms of the agreements 422 that are createdbetween the customer 402 the merchant 450, and the verification entity420 and/or the financial institution 440 are stored by the verificationentity 420. The verification entity 420 can be included within thefinancial institution (credit issuer) 440 as shown in FIG. 5, or beseparate therefrom, as shown in FIG. 4. While FIG. 4 illustrates asingle customer's computer 410, a single verification entity 420, asingle financial institution 440, and a single merchant 450, as would beunderstood by those ordinarily skilled in the art, FIG. 4 is only oneexample of how the invention could be implemented and there could be(and most likely would be) multiple customer's computers 410, multipleverification entities 420, multiple financial institutions 440, multiplemerchants 450, etc. as shown in FIG. 5. Therefore, the verificationentity 420 stores multiple agreements 422, one for each purchasetransaction.

The method includes registering and storing the customer agreement(s)422 with the credit issuer/verification entity 440/420. The customerinformation is stored in a database 430, which can be within the creditissuer/verification entity 440/420 as shown in FIG. 5, or as shown inFIG. 4, separate from the credit issuer/verification entity 440/420. Aswould be understood by those ordinarily skilled in the art, while onlyone database 430 is illustrated in FIG. 4, there could be multipledatabases 430, some of which could be included within the creditissuer/verification entity. Further, the customer's computer 410 isconnected to the merchant 450 and the verification entity 420 over oneor more computer networks 404.

A password is used to access an encoder 412 on the customer's computer410. The encoder 412 is downloaded to the customer's computer 410 by theverification entity 420 during the customer registration process. Theencoder 412 encrypts the customer information to form the encryptionstream 414 which is stored on the customer's computer 410. The customerinformation is not stored on the customer's computer in non-encryptedform. Further, the encryption stream does not include any personalfinancial customer information relating to credit card numbers, bankaccount numbers, etc. and such information is stored only in thedatabase(s) 430.

In addition, the verification entity downloads transfer agents 416, 456to the customer's computer 410 and to the merchant 450. The transferagent 416 causes the encryption stream 414 to be transferred from thecustomer's computer to the merchant's computer 450 in the purchasetransaction for the purchased electronic item 454.

The verification entity 420 has a verifier 424 that is operativelyconnected to both the customer's computer 410 and the merchant'scomputer 450. In embodiments herein, in order to enhance the security ofthe customer information, the verifier 424 is maintained separate fromthe customer's computer 410 and from the merchant by being maintained inthe credit issuer/verification entity 440/420. The database 430 of thecustomer payment information can be maintained within the creditissuer/verification entity 440/420 or separate from the verificationentity 420. In either situation, the database 430 is operativelyconnected only to the verifier 424, and neither the customer nor themerchant have access to the database.

To perform the method steps herein, the transfer agent 416 is adapted tocause the encryption stream 414 to be transferred (along with themonetary amount of the transaction) from the merchant's computer 450 tothe verifier 424 for payment verification. The verifier 424 is furtheradapted to generate the payment verification, based on the database 430,and to transfer the payment verification to the merchant 450. Again, theencryption stream 414 and/or a transaction identifier is adapted to beadded, by the merchant, to the purchased electronic item to create thepersonalized electronic item 454 (as shown in FIG. 6) that is suppliedfrom the merchant 450 to the customer's computer 410.

The encryption stream 414 can include such information as the customer'sname, a customer shipping address, customer's date of birth andcustomer's hardware computer identifier. The customer shipping addresscan comprise one of a plurality of valid shipping addresses that dependupon which encryption stream 414 is supplied to the merchant 450. Thus,the method can allow the customer to select from a plurality of storedencryption streams 414, each having a different valid shipping address.The method supplies the selected encryption stream 414 together with thecomputer identifier as part of the identifier code (the CID and routingidentifier 416) to the merchant 450 in a transaction over the computernetwork 404.

The encryption stream 414 is forwarded, by means of the routingidentifier 416, to the verification entity 420 over the computer network404. The verification entity 420 decrypts the encryption stream 414 andcompares the customer shipping address identifier, name identifier, ageidentifier, or other identifiers with the authorized correspondingidentifiers of the customer maintained by the verification entity 420such as “identifiers” of name, age, address, etc., can be actual names,addresses, etc., or can be alpha-numeric codes that are used by theverification entity 420 to look up the name, address, age, etc., in thedatabase 430. If all is in order, the verification entity 420 returns anauthorization decision to the merchant 450 over the computer network404. Thus, the verification entity 420 can produce (and return to themerchant) the identity verification, payment authorization, etc. Theverification entity 420 verifies that the terms of the customer'sverified presence and electronic signature have been met according tocustomer's agreement 422 with the verification entity 420, whichconfirms to the merchant 450 that the customer has assumedresponsibility for the transaction.

In addition, each of the encryption streams 414 can include a uniquepayment method that is different from payment methods of otherencryption streams 414. Alternatively, a group of the encryption streams414 can identify a single credit organization for payment, but eachencryption stream 414 in the group can include a different user name, adifferent authorized and registered device/computer, different ageverification method, and/or different customer address.

For purchase transactions that include services or tangible goods (suchas stereo equipment, filters, books, groceries, clothing, furniture,computers, etc.), the embodiments herein can subside in supplying averification of the customer and a payment authorization. However, forpurchase transactions that include electronic items which have thepotential to be improperly shared over computer networks, theembodiments herein can add the encryption stream or a transactionidentifier to the electronic item. Thus, as part of the agreement 422,the customer agrees to allow the encryption stream 414 and routingidentifier 416 to be imbedded, imprinted, and/or otherwise affixed tomedia or media content 454 acquired from the merchant 450, as shown inFIG. 6. Before transferring the encryption stream 414 to the merchant450, the verification entity can add the encryption stream, which cancontain a customer agreement or customer agreement identifier, or thetransaction identifier to the encryption stream 414 to allow thecustomer agreement 422 between the customer 402 and the merchant 450 tobe readily accessed.

This process also establishes the jurisdiction for enforcement of themerchant's 404 rights as established in the customer's agreement 422.The authorization decision is approved only if the encryption stream 414and the customer information within the database 430 are consistent. Themethod can send an e-mail confirmation of the transaction to thecustomer 414 from the verification entity 420. The encryption stream414/CID is stored on the customer storage device 408 only in encryptedform.

As shown in flowchart form in FIG. 7, the disclosed method facilitatesthe computerized purchase transactions of electronically storable items(which are sometimes referred to herein as electronic items) such asliterary works, musical works (recordings), video works (movies, shows,videos, etc.), etc.

First, in item 700, the customer enters into the customer agreement withthe verification entity. Then, in item 702, the embodiments hereinencrypt “customer information” to produce an encryption stream 704.Techniques for data encryption are disclosed in, for example, U.S. Pat.Nos. 7,257,225 and 7,251,326 (incorporated herein by reference) and thedetails of such processes are not provided herein to maintain focus onthe disclosed embodiments. Such customer information may comprise a nameidentifier (which may or may not be the customer's formal name), acustomer age identifier (which can be a specific age, an age range, anage classification), an address identifier (which can be a customer'saddress or a different address).

In item 706, the embodiments herein cause the encryption stream to betransferred from the customer to a merchant in the purchase transactionfor the purchased electronic item. The verification entity receives theencryption stream which is sent by the merchant for payment verificationin item 708. Then, the verification entity cross-references theencryption stream against a separate database containing customerpayment information (item 710) to produce the unique transactionidentifier comprising the identity verification and/or paymentauthorization in item.

The verification entity transfers the unique transaction identifier fromthe verification entity to the merchant in item 714. The identityverification and payment authorization confirms to the merchant theactual presence of the customer in the purchase transaction, such thatthe merchant is provided assurance that the merchant is not transactingwith any entity other than the customer.

As mentioned above, the encryption stream 704 and the identityverification and payment authorization 710 are devoid of personalpayment information of the customer, such as credit card information,bank account information, etc., and can take the form of a uniquetransaction identifier. Thus, even if the encryption stream isdecrypted, the customer's payment information would not be disclosed orusable. Thus, the encryption stream supplied from the customer can bemodified by the verification entity before being supplied to themerchant to include data or information specific to the purchasetransaction being conducted or the encryption stream can be accompaniedby the unique transaction identifier. Such a modified encryption streamor unique transaction identifier can be used in place of the originalencryption stream in embodiments herein. Thus, the original encryptionstream, the modified encryption stream, and/or the unique transactionidentifier can be added to the electronic item before being provided tothe customer.

For embodiments that deal with electronic items that have the potentialof being improperly copied and distributed over computerized networks,as shown in item 716, the encryption stream and/or unique transactionidentifier is added, by the merchant, to the purchased electronic itemto create a personalized electronic item 718. The encryption steam ortransaction identifier can be hidden, so that the customer is unable toremove the encryption stream or transaction identifier from thepersonalized electronic item. Techniques for embedding information in adigital work are well-known (see U.S. Pat. Nos. 6,691,229 and 5,809,160,which are incorporated herein by reference for details of suchteachings). Further, the personalized electronic item could be madenon-functional (so that the personalized electronic item cannot beopened, or cannot be played, etc.) if the encryption stream ortransaction identifier is ever removed. Techniques for controllingaccess to digital works through encryption streams or watermarks arealso well-known (see U.S. Pat. No. 7,062,069 which is incorporatedherein by reference for details of such teachings).

Thus, the personalized electronic item always maintains the encryptionstream and allows the customer who purchased the electronic item to beidentified (through the verification entity) and all copies of thepurchased electronic item will have the encryption stream or transactionidentifier. Thus, because all copies of the personalized electronic itemwill have the encryption stream, the customer who originally purchasedthe electronic item from the merchant (the source of the copies) canalways be identified.

After the encryption stream or transaction identifier is added to thepurchased electronic item, the personalized electronic item is suppliedfrom the merchant to the customer in item 720. Each personalizedelectronic item distributed to different customers is different becauseof the uniqueness of each different encryption stream or transactionidentifier, which allows the customer who originally purchased theelectronic item to be identified in copies of the electronic item.Further, the uniqueness of each encryption stream or transactionidentifier permits the source of unauthorized copies of the purchasedelectronic item to be identified through the verification entity. Thus,as shown in item 722, the method potentially includes the step ofidentifying the customer from the encryption stream that is includedwithin the personalized electronic item.

During customer registration (when the customer is setting-up ormodifying their account with the credit issuer) and during the purchaseof electronic items, the customer is provided a notice or warning thattheir information will always remain with copies of any personalizedelectronic items. In addition, during the purchase of an electronicitem, a similar notice or warning is displayed informing the customerthat he/she is agreeing to be bound by the terms and penalties providedfor unauthorized use or copying of the electronic item; and, each time(or the first few times) the personalized electronic item is opened,played, etc. the same warning may be displayed. Such warnings areintended to discourage the customer from supplying copies of thepersonalized electronic item to others in violation of the rights of themerchant (e.g., illegally uploading or copying) because the customer ismade aware, through the warnings, that the illegal uploading or copyingcan be traced back to them through the verification entity using theencryption stream and is agreeing to be bound by the conditions andterms set forth in those warnings. Similar authorized use and acceptancewarnings may also be employed for access based upon age, sale pricingbased upon age or residence, etc. The embodiments herein allow for awide range of customer identifiers that encourage, promote, and protecteCommerce and the parties engaging in it.

The encrypting of the customer information 702 is performed as shown inFIG. 8. First, the customer connects with the credit issuer using afirst computerized device 800 and the verification entity downloads somesoftware to the first computerized device 802. The customer supplies oragrees to allow access to existing sensitive information, such as validshipping addresses, their date of birth (or age group classification),their bank account numbers, credit card numbers, etc. to theverification entity 804. Certain items of the customer information (suchas bank account numbers and credit card numbers) are not stored on thecustomer's computerized device, but instead are only maintained in thedatabases of the credit issuer and/or verification entity, though codedor un-coded identifiers may be used to specifically reference suchinformation. Other items or identifiers (name, address, age reference,etc.) of the customer information may be encrypted to create theencryption stream, which is stored on the customer's computerized deviceand which may be coded or un-coded prior to encryption, in part or inwhole.

With the customer's authorization, the credit issuer reads and registersthe unique hardware identifiers (such as serial numbers from themotherboard, the hard drives, the processor, etc.) from the firstcomputerized device in item 806. These unique hardware identifiers arealso incorporated into the encryption stream in item 808. Then, the samesteps are repeated for any additional computerized devices the customerdesires to authorize and register for use in future purchasetransactions. Such processes can be done when the customer is setting upor modifying their account with the credit issuer.

Use of a “public” or “unregistered” computer is also covered under thisapplication. It is possible to “allow” emergency access to an individualif they access their “issuer account” form the “unregistered” computerand arrange for a “limited” approval of that computer under theirexisting account, which approval could be time-limited (e.g., 15-minutesfor a single purchase) or use-limited (e.g., one-time use/singlepurchase).

In another embodiment, as one process of further verifying that themerchant is dealing with no one else other than the customer, at theapproximate time of transfer of the encryption stream to the merchant,but before the actual transfer of the encryption stream to the merchant(as part of the process of transferring the encryption stream) themethod can incorporate, into the encryption stream, a second set ofhardware identifiers and a time and date stamp from the computerizeddevice making the actual transfer of the encryption stream. Therefore,as shown in FIG. 9, after the hardware identifiers have been added tothe encryption stream in item 900, the method reads a second set ofhardware identifiers from the actual computer that is connected to themerchant in item 902. This second set of hardware identifiers (andpotentially a time and date stamp) are then added to the encryptionstream in item 904 and the modified encryption stream (having both setsof hardware identifiers) to the merchant in item 906.

Thus, if an unscrupulous person were able to obtain an improper copy ofthe encryption stream, and was using the improper copy of the encryptionstream on a computer (other than one of the customer's computers thatare registered with the merchant) together with the necessary creditissuer supplied encryption stream creation and transfer software thesecond hardware identifiers that are readjust prior to the transfer ofthe encryption stream would not match the first hardware identifiers inthe encryption stream and the transaction would not be approved by theverification entity. Similarly, the time and date stamp could be used tomake the encryption stream that is supplied to the merchant only validfor a limited time period (e.g., minutes, hours, days, etc.). Suchprocesses further enhance the “customer presence” verification processperformed by the verification entity to provide additional assurances tothe merchant that they are actually dealing with the customer and notsomeone other than the actual customer.

The embodiments of the invention can take the form of an entirelyhardware embodiment, an entirely software embodiment or an embodimentincluding both hardware and software elements. In one embodiment, theinvention is implemented in software, which includes but is not limitedto firmware, resident software, microcode, etc.

Furthermore, the embodiments of the invention can take the form of acomputer program product accessible from a computer-usable orcomputer-readable medium providing program code for use by or inconnection with a computer or any instruction execution system. For thepurposes of this description, a computer-usable or computer readablemedium can be any apparatus that can comprise, store, communicate,propagate, or transport the program for use by or in connection with theinstruction execution system, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system (or apparatus or device) or apropagation medium. Examples of a computer-readable medium include asemiconductor or solid state memory, magnetic tape, a removable computerdiskette, a random access memory (RAM), a read-only memory (ROM), arigid magnetic disk and an optical disk. Current examples of opticaldisks include compact disk-read only memory (CD-ROM), compactdisk-read/write (CD-R/W) and DVD.

A data processing system suitable for storing and/or executing programcode will include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output (I/O) devices (including but not limited to keyboards,displays, pointing devices, etc.) can be coupled to the system eitherdirectly or through intervening I/O controllers. Network adapters mayalso be coupled to the system to enable the data processing system tobecome coupled to other data processing systems or remote printers orstorage devices through intervening private or public networks. Modems,cable modem and Ethernet cards are just a few of the currently availabletypes of network adapters.

A representative hardware environment for practicing the embodiments ofthe invention is depicted in FIG. 10. This schematic drawing illustratesa hardware configuration of an information handling/computer system inaccordance with the embodiments of the invention. The system comprisesat least one processor or central processing unit (CPU) 10. The CPUs 10are interconnected via system bus 12 to various devices such as a randomaccess memory (RAM) 14, read-only memory (ROM) 16, and an input/output(I/O) adapter 18. The I/O adapter 18 can connect to peripheral devices,such as disk units 11 and tape drives 13, or other program storagedevices that are readable by the system. The system can read theinventive instructions on the program storage devices and follow theseinstructions to execute the methodology of the embodiments of theinvention. The system further includes a user interface adapter 19 thatconnects a keyboard 15, mouse 17, speaker 24, microphone 22, and/orother user interface devices such as a touch screen device (not shown)to the bus 12 to gather user input. Additionally, a communicationadapter 20 connects the bus 12 to a data processing network 25, and adisplay adapter 21 connects the bus 12 to a display device 23 which maybe embodied as an output device such as a monitor, printer, ortransmitter, for example.

The foregoing description of the specific embodiments will so fullyreveal the general nature of the invention that others can, by applyingcurrent knowledge, readily modify and/or adapt for various applicationssuch specific embodiments without departing from the generic concept,and, therefore, such adaptations and modifications should and areintended to be comprehended within the meaning and range of equivalentsof the disclosed embodiments. It is to be understood that thephraseology or terminology employed herein is for the purpose ofdescription and not of limitation. Therefore, while the embodiments ofthe invention have been described in terms of preferred embodiments,those skilled in the art will recognize that the embodiments of theinvention can be practiced with modification within the spirit and scopeof the appended claims.

1. A method comprising: encrypting customer information in an encryptionstream, wherein said customer information comprises a name identifier, acustomer age identifier, an address identifier, and a customer agreementidentifier; causing said encryption stream to be transferred from acustomer to a merchant in a purchase transaction for a purchasedelectronic item; causing said encryption stream to be routed to averification entity; producing, by said verification entity, a uniquetransaction identifier comprising at least one of an identityverification and a payment authorization, based on said encryptionstream; transferring, by said verification entity, said uniquetransaction identifier to said merchant, wherein said encryption streamand said unique transaction identifier are devoid of personal paymentinformation of said customer; causing at least one of said encryptionstream and said unique transaction identifier to be added, by saidmerchant, to said purchased electronic item to create a personalizedelectronic item; and causing said personalized electronic item to besupplied from said merchant to said customer, wherein each personalizedelectronic item supplied to different customers is different because ofa uniqueness of each encryption stream.
 2. The method according to claim1, wherein said encrypting of said customer information furthercomprises steps of: a) causing said customer to connect with saidverification entity using a first computerized device; b) readinghardware identifiers from said first computerized device; c)incorporating said hardware identifiers into said encryption stream; andd) repeating steps a-c for additional computerized devices said customerdesires to use in any purchase transaction.
 3. The method according toclaim 2, wherein said causing of said encryption stream to betransferred from said customer to said merchant further comprises: at anapproximate time of transfer of said encryption stream to said merchant,but before actual transfer of said encryption stream to said merchant,incorporating, into said encryption stream, a second set of hardwareidentifiers and a time and date stamp from a computerized device makingsaid actual transfer; and attaching a non-encrypted routing identifierto said encryption stream.
 4. The method according to claim 1, whereinsaid identity verification and said payment authorization confirms tosaid merchant an actual presence of said customer in said purchasetransaction, such that said merchant is provided assurance that saidmerchant is not transacting with any entity other than said customer,and such that said transaction identifier allows said merchant to submitthe transaction for signature present processing.
 5. The methodaccording to claim 1, wherein said uniqueness of each encryption streampermits the source of unauthorized copies of said purchased electronicitem to be identified through said verification entity.
 6. A methodcomprising: encrypting customer information in an encryption stream,wherein said customer information comprises a name identifier, acustomer age identifier, an address identifier, and a customer agreementidentifier; causing said encryption stream to be transferred from acustomer to a merchant in a purchase transaction for a purchasedelectronic item; causing said encryption stream to be routed to averification entity; producing, by said verification entity, a uniquetransaction identifier comprising at least one of an identityverification and a payment authorization, based on said encryptionstream; cross-referencing, by said verification entity, said encryptionstream against a separate database comprising customer information toproduce said unique transaction identifier; transferring, by saidverification entity, at least one of said identity verification and saidpayment authorization to said merchant, wherein said encryption stream,said identity verification, and said payment authorization are devoid ofpersonal payment information of said customer; causing at least one ofsaid encryption stream and said identity verification and said paymentauthorization to be added, by said merchant, to said purchasedelectronic item to create a personalized electronic item; and causingsaid personalized electronic item to be supplied from said merchant tosaid customer, wherein each personalized electronic item supplied todifferent customers is different because of a uniqueness of eachencryption stream.
 7. The method according to claim 6, wherein saidencrypting of said customer information further comprises steps of: a)causing said customer to connect with said verification entity using afirst computerized device; b) reading hardware identifiers from saidfirst computerized device; c) incorporating said hardware identifiersinto said encryption stream; and d) repeating steps a-c for additionalcomputerized devices said customer desires to use in any purchasetransaction.
 8. The method according to claim 7, wherein said causing ofsaid encryption stream to be transferred from said customer to saidmerchant further comprises: at an approximate time of transfer of saidencryption stream to said merchant, but before actual transfer of saidencryption stream to said merchant, incorporating, into said encryptionstream, a second set of hardware identifiers and a time and date stampfrom a computerized device making said actual transfer; and attaching anon-encrypted routing identifier to said encryption stream.
 9. Themethod according to claim 6, wherein said identity verification and saidpayment authorization confirms to said merchant an actual presence ofsaid customer in said purchase transaction, such that said merchant isprovided assurance that said merchant is not transacting with any entityother than said customer, and such that said transaction identifierallows said merchant to submit the transaction for signature presentprocessing.
 10. The method according to claim 6, wherein saidcross-referencing comprises verifying whether all required verificationinformation is contained within said encryption stream before producingsaid identity verification and payment authorization.
 11. A methodcomprising: encrypting customer information in an encryption stream,wherein said customer information comprises at least one of a nameidentifier, a customer age identifier, an address identifier, and acustomer agreement identifier; causing said encryption stream to betransferred from a customer to a merchant in a purchase transaction fora purchased electronic item; causing said encryption stream to be routedto a verification entity; producing, by said verification entity, aunique transaction identifier based on said encryption stream;transferring, by said verification entity, a unique transactionidentifier to said merchant, wherein said encryption stream and saidunique transaction identifier are devoid of personal payment informationof said customer; causing said encryption stream to be added, by saidmerchant, to said purchased electronic item to create a personalizedelectronic item; and causing said personalized electronic item to besupplied from said merchant to said customer, wherein each personalizedelectronic item supplied to different customers is different because ofa uniqueness of each encryption stream.
 12. The method according toclaim 11, wherein said encrypting of said customer information furthercomprises steps of: a) causing said customer to connect with saidverification entity using a first computerized device; b) readinghardware identifiers from said first computerized device; c)incorporating said hardware identifiers into said encryption stream; andd) repeating steps a-c for additional computerized devices said customerdesires to use in any purchase transaction.
 13. The method according toclaim 12, wherein said causing of said encryption stream to betransferred from said customer to said merchant further comprises: at anapproximate time of transfer of said encryption stream to said merchant,but before actual transfer of said encryption stream to said merchant,incorporating, into said encryption stream, a second set of hardwareidentifiers and a time and date stamp from a computerized device makingsaid actual transfer; and attaching a non-encrypted routing identifierto said encryption stream.
 14. The method according to claim 11, whereinsaid identity verification and said payment authorization confirms tosaid merchant an actual presence of said customer in said purchasetransaction, such that said merchant is provided assurance that saidmerchant is not transacting with any entity other than said customer,and such that said transaction identifier allows said merchant to submitsaid purchase transaction for signature present processing.
 15. Themethod according to claim 11, wherein said uniqueness of each encryptionstream permits the source of unauthorized copies of said purchasedelectronic item to be identified through said verification entity.
 16. Amethod comprising: encrypting customer information in an encryptionstream, wherein said customer information comprises a customer agreementidentifier; causing said encryption stream to be transferred from acustomer to a merchant in a purchase transaction for a purchase, whereinsaid purchase comprises one of a good and a service; causing saidencryption stream to be routed to a verification entity; producing, bysaid verification entity, an identity verification and a paymentauthorization based on said encryption stream; and transferring, by saidverification entity, at least one of said identity verification and saidpayment authorization to said merchant, wherein said encryption stream,said identity verification, and said payment authorization are devoid ofpersonal payment information of said customer.
 17. The method accordingto claim 16, wherein said encrypting of said customer informationfurther comprises steps of: a) causing said customer to connect withsaid verification entity using a first computerized device; b) readinghardware identifiers from said first computerized device; c)incorporating said hardware identifiers into said encryption stream; andd) repeating steps a-c for additional computerized devices said customerdesires to use in any purchase transaction.
 18. The method according toclaim 17, wherein said causing of said encryption stream to betransferred from said customer to said merchant further comprises: at anapproximate time of transfer of said encryption stream to said merchant,but before actual transfer of said encryption stream to said merchant,incorporating, into said encryption stream, a second set of hardwareidentifiers and a time and date stamp from a computerized device makingsaid actual transfer; and attaching a non-encrypted routing identifierto said encryption stream.
 19. The method according to claim 16, whereinsaid identity verification and payment authorization confirms to saidmerchant an actual presence of said customer in said purchasetransaction, such that said merchant is provided assurance that saidmerchant is not transacting with any entity other than said customer,and such that said transaction identifier allows said merchant to submitthe transaction for “signature present” processing.
 20. A servicecomprising: encrypting customer information in an encryption stream,wherein said customer information comprises a name identifier, acustomer age identifier, an address identifier, and a customer agreementidentifier; causing said encryption stream to be transferred from acustomer to a merchant in a purchase transaction for a purchasedelectronic item; causing said encryption stream to be routed to averification entity; producing, by said verification entity, a uniquetransaction identifier comprising at least one of an identityverification and a payment authorization, based on said encryptionstream; transferring, by said verification entity, said uniquetransaction identifier to said merchant, wherein said encryption streamand said unique transaction identifier are devoid of personal paymentinformation of said customer; causing at least one of said encryptionstream and said unique transaction identifier to be added, by saidmerchant, to said purchased electronic item to create a personalizedelectronic item; and causing said personalized electronic item to besupplied from said merchant to said customer, wherein each personalizedelectronic item supplied to different customers is different because ofa uniqueness of each encryption stream.
 21. A system comprising: anencoder positioned within a customer computer, wherein said encoder isadapted to encrypt customer information in an encryption stream, whereinsaid customer information comprises a name identifier, a customer ageidentifier, an address identifier, and a customer agreement identifier;a transfer agent positioned within said customer computer, said transferagent causing said encryption stream to be transferred from saidcustomer computer to a merchant computer in a purchase transaction for apurchased electronic item; a verifier operatively connected to saidmerchant computer, wherein said verifier is separate from said customercomputer and from said merchant; and a database comprising said customerinformation operatively connected to said verifier, wherein saidtransfer agent is adapted to cause said encryption stream to betransferred from said merchant computer to said verifier, wherein saidverifier is adapted to generate a unique transaction identifiercomprising an identity verification and/or a payment authorization,based on said database, and to transfer said unique transactionidentifier to said merchant, wherein said encryption stream and saidunique transaction identifier are devoid of said personal paymentinformation of said customer, wherein at least one of said encryptionstream and said unique transaction identifier is adapted to be added, bysaid merchant, to said purchased electronic item to create apersonalized electronic item to be supplied from said merchant to saidcustomer, and wherein each personalized electronic item supplied todifferent customers is different because of a uniqueness of eachencryption stream.